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Abstract 



1. Introduction 

The proposed new MAC is distributed, i.e. all devices have the same protocol 
behavior and hardware/software capabilities. This makes the protocol very well suited 
for ad hoc applications and peer to peer networking. Furthermore, the proposed MAC 
is based on medium reservations of the devices, which eliminates sensing and 
collision times on the medium. Owing to the medium reservations, a very efficient 
real-time, rsp. streaming support is guaranteed, the data throughput is increased and 
the mesh networking support significantly improved. Another important characteristic 
of the protocol is that reservations are issued by the receiver of a packet or burst of 
packets. This avoids the hidden-terminal problem, which is otherwise hampering an 
efficient operation in mesh networking scenarios. Finally, a sophisticated beaconing 
concept allows for very efficient power save modes without interrupting large packet 
bursts. The beaconing can further be used for the mutual device discovery in the ad 
hoc network. 




2. Protocol Description 



2.1. Overall superframe layout 

The time is divided into superframes, as shown in Figure 1 . At the beginning of each 
superframe there is a beacon period followed by a data transmission phase. 
The beacons within the beacon phase are separated by a "Short Beacon Inter-frame 
Space" (SBIS). The beacon interval is separated from the data transmission phase by a 
"End Beacon Interval Space" (EBIS). 
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Figure 1 : Overall superframe layout 



2.2.MAC Protocol Operation 

Before the two phases "beacon phase" and "data phase" are described in more detail, 
an overview of the Medium Access Control (MAC) protocol operation is given in this 
section. 

Devices, which are planning a data transmission, propose a starting point in time, 
duration, priority, etc. of the transmission to the intended receiver(s) of the planned 
transmission. A dedicated "Reservation-Request" management frame is used for this 
purpose. The receiver evaluates whether the medium is free on his side during the 
planned transmission time in the future. In order to be able to carry out this 
evaluation, every device shall locally store the reservations of all other devices. If the 
receiver has no other reservation stored for the intended period, it gives a positive 
response to the sender of the Reservation-Request. A dedicated "Reservation- 
Response" management frame is used for that purpose. In case that the receiver is not 
willing to accept the transmission or in case that it has stored another reservation 
during the planned time, the receiver sends a negative Reservation-Response to the 
sender. In this negative Reservation-Response the receiver can optionally propose an 
alternative time for the planned transmission. 

If sender and receiver have successfully negotiated a reservation, both devices include 
the reservation information in their respective beacon-frames in the subsequent MAC- 
superframe. The beacons are transmitted in the beacon-phase at the beginning of a 
superframe. The reason to include the reservation information in the beacon is to 
inform all devices surrounding the sender and the receiver, about the forthcoming 
transmission. Devices, which receive such reservation information in the beacon of 
another device, shall store this reservation information locally and shall defer from 



any medium access at the announced point in time on the respective channel hopping 
sequence and for the duration of the planned transmission. In other words, the locally 
stored reservation information is used to determine free time on the wireless medium 
for own transmissions, in which the device is either sender or receiver of the 
transmission. For their own transmissions the devices shall select periods, in which no 
reservations of other devices are registered. The process of Reservation-Request, 
Reservation-Response, announcement in the beacon frames of the involved devices 
and subsequent data transmission is illustrated in Figure 1 . 
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Figure 1: Overview of MAC protocol operation 

The protocol allows for a dynamic reservation of transmissions in every superframe. 
However, in order to save the overhead of the Reservation-Request and Reservation- 
Response message exchange, a reservation shall be automatically interpreted as 
reservation not only for the subsequent superframe but also for all following 
superframes. In case that the sender wants to change the reservation it shall distribute 
a new reservation information inside its beacon. If the sender has ended the 
connection, it shall include a reservation information in its beacon with the same 
starting time as the corresponding previous reservation but with zero duration. Upon 
reception of a reservation information with zero duration, the devices shall locally 
delete the corresponding reservation information. 

In case that a device receives a reservation information for a time in the future, for 
which the device wanted to reserve the medium itself, the device is only allowed to 
distribute this own reservation, if the priority of the planned transmission is higher 
than the priority of the received reservation. In case of equal priorities the medium is 
reserved in a first come, first served order. If a device detects that its own reservation 
is overruled by another device, it shall cancel its planned transmission and toy to make 
a new reservation in a subsequent superframe. All devices should modify their locally 
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stored reservation information, in case that they receive a reservation with a higher 
priority for the same or an overlapping time-period. 

Summarizing the following rules shall be applied when a station tries to reserve the 
medium. If the medium is already reserved to a station, another station may override 
this reservation only when its reservation is of higher priority. The station whose 
reservation is overridden will delay its reservation since it overhears another 
reservation of higher priority. If the channel is already reserved by a reservation of the 
same priority the reservation which is existing on a longer term may not be delayed 
by other reservations. 



2.3. Beacon phase 



During the beacon period all devices that are either in active state or in standard 
power-save mode shall transmit their own beacon. The frame body of a beacon shall 
contain at least the following fields and information elements (IE), as illustrated in 
Figure 2: 

Beacon number field 
Device Identifier (MAC-address) field 
Sleep period field 

Device capability information element 
Beacon position occupancy information element 
Zero, one or several "Reservation information elements" 
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Figure 2: Structure of a device beacon 

The beacon number shall represent the order of the beacons, i.e. the first beacon shall 
have the number 1, the second beacon in the superframe the number 2, etc. With a 
beacon number field size of 8 bit, 256 devices can be supported simultaneously. 
The device ID is the 48 bit MAC address of the device. The DEV-cap information 
element contains information regarding the capabilities of the device. The sleep 
period field gives the period in number of superframes, during which the device will 
be in deep sleep-mode, which will be described in more detail in section 2.5. 
The "beacon position occupancy" information element contains a list of received 
beacons of other devices. Each element in the beacon position occupancy field shall 
contain the number of the beacon (position), a short device ID of the device, which 
has sent the beacon, as well as the duration of the beacon in symbols (multiples of 
312.5 ns) (see Figure 3). The beacon position occupancy field is required in each 
beacon, because other devices have to be informed, whether their beacon has been 
successfully received or whether a beacon collision has occurred. The latter can be 
due to the fact that two devices have randomly chosen the same beacon position or 
due to a hidden terminal problem in mesh network scenarios. In the latter scenario a 
device might receive two beacons from different devices at the same position in the 
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beacon phase, if these two other devices could not hear each other and are not aware 
of the other device's beacon position. 

The duration of the beacon has to be given in order to inform devices, which are not 
able to receive this beacon, when the beacon will end. 
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Figure 3: Structure of the "Beacon Position Occupancy" information element 

The reservation information element shall only be included, if the device is either 
sender or receiver of a future transmission in this superframe. The reservation 
information element contains the following parameter, as shown in Figure 4: 

• The element ID (of a reservation element) 

• The length of the BE 

• A "Tx/Rx bif \ which indicates whether the device is sender or receiver 

• The ID of the communication partner (or multicast group) of the planned 
transmission 

• The Target Beacon Transmission Time (TBTT) offset, which indicates the starting 
point of the reserved transmission in the current superframe, measured as offset 
from the TBTT of this device. 

• The duration of the reservation 

• The priority of the planned transmission 

• The channel hopping sequence of the planned transmission 



Element 
ID 


Length 


TX/RX 


Desi/ 

Source 

ID 


TBTT 
Offset 


Duration 


Priority 


Hopping 
sequence i 



Bits: 8 



8 1 TBD 19 19 3 6 

Figure 4: Structure of the Reservation Information Element 

The "Tx/Rx bit" shall be set to "0", if the device is sender of the planned transmission 
and set to "1", if the device is a receiver of the planned transmission. The ID of the 
communication partner shall be the ID of the receiver or multicast-group in case that 
the device is the sender of the transmission and shall be the ID of the sender in case 
that the device is a receiver of the planned transmission. 

The starting point of the planned transmission is given relative to the beginning of the 
respective beacon in multiples of symbols (312.5 ns). The duration of the planned 
transmission is also given in multiples of symbols (312.5 ns). The priority of the 



transmission can have a value between 0 and 7, where the priority is chosen according 
to IEEE 802. 1 d Annex H.2. 

The channel hopping sequence of the planned transmission is given in order to allow 
for parallel transmissions of other devices in case that the resulting Signal-to-Noise 
ratio would be sufficient. 

As mentioned before, the beacons within the beacon phase are separated by a "Short 

Beacon Inter-frame Space'* (SBIS).the beacon interval is separated from the data 

transmission phase by a "End Beacon Interval Space" (EBIS). 

The length of the beacon phase can be variable, as devices might join or leave the 

network. A variable beacon phase has the big advantage that the overhead of the 

beaconing gets minimal in typical cases of one sending and one or a few receiving 

devices. 

If a new device joins the network it shall listen to at least one full first beacon interval 
and evaluate the information inside the beacons. From the received beacons as well as 
the "beacon position occupancy" fields, the new device shall deduce occupied beacon 
positions. In the same or the following superftame (depending on the processing 
speed of the device), the device shall transmit its beacon SBIS time after the (last) 
beacon with the highest beacon number in the first beacon phase. If two devices have 
chosen the same additional beacon position/number, e.g. that they have joined the 
network in the same superframe, the devices will detect the collision in the following 
superftame by the missing "beacon position occupancy" information. In such a case a 
device shall re-transmit its beacon in the superframe, which followed the last try, at 
the same position with a probability of 1/n+l, where n is the number of the current 
trial. 

A back-off of the additional beacon transmission is not possible because the other 
devices would interpret the pause time after the last beacon as the end of the beacon 
phase. 

If a device has left the network, its old beacon position will be empty. In such a case, 
all the devices with higher beacon numbers, which detect the missing beacon, shall 
decrease their beacon number by 1 and shift the sending of their beacon accordingly 
in the beacon that follows the change. 

Empty beacon positions will not be "re-filled" by new devices that join the network, 
because no new device might join after another one has left. Waiting for a new device 
to join and re-fill the empty position would waste precious frequency resources. 

2.4.Data transmission phase 

A data transmission is always initiated by the receiver of the transmission by sending 
a Poll-frame to the sender. This has the advantage that the sender will only start its 
transmission, if it is ensured that the medium around the receiver is clear. 

The receiver shall perform a back-off before sending the Poll-frame, which shall start 
at the given start-time of the transmission or after the end of any ongoing 
transmission, whatever ends later. Even though the reservation mechanism should 
exclude any collisions, it might still be possible that a device has not received the 
reservation information, in which case the back-off can eliminate a potential collision. 
However, as the reservation mechanism makes a collision very improbable, the back- 
off can be very short. 
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A "Short Data Infer-frame Space "(SDIS) time, after the reception of the Poll-frame, 
the sender shall start the transmission of the data frame. 

The sender can also send a burst of data packets, in which packets are separated by 

SDIS pause times. As the SDIS may be very short, it might be possible to waive the 

usage of OFDM preambles - which are needed to synchronize the receiver - since the 

receiver may be still synchronized to the transmitter. 

The receiver acknowledges a single or a burst of packets by an ACK frame. 

The ACK-frame contains information, which acknowledges each preceding data 

packet, thus allowing a selective reject of failed frames. 

The sender shall ensure that the time required for the back-off of the receiver, the 
Poll-frame, SDIFS, the burst of packets and the ACK does not exceed the length of 
the reservation. In case that a transmission of another device had blocked a certain 
interval during the reserved interval, the sender shall reduce the amount of data sent 
accordingly in order to guarantee the ending of the transmissions on schedule. 

2.5.Power Management 

All devices in the so-called "Standard Power-save Mode" shall be awake during the 
beacon phase, shall send a beacon and can go into sleep for the rest of the superframe, 
m case that they are not mentioned as receivers of planned transmissions of other 
devices. 

Devices in "Active Mode" can fall asleep after their own transmission/reception until 
the beginning of the next beacon phase. 

Devices can also enter a "Deep Power-save Mode". In this power-save mode devices 
can fell asleep for more than one superframe in a row without waking up for the 
intermediate beacon phases. For this purpose a device shall signal in its beacon the 
number of superframes, in which the device will not listen to the beacon phase and 
not send an own beacon. The devices, which received the beacon of the device in 
deep power-save, shall store this information and shall not attempt any data 
transmissions directed to the sleeping device during its sleep phase. Furthermore, the 
other devices shall include the beacon of the sleeping device in the "beacon position 
occupancy field" in their own beacon, even though no beacon from the sleeping 
device was received. The reason is that new or moving devices should not occupy the 
beacon position of the sleeping device. 

A device in Deep-Power Save shall not announce any planned reservations in the 
beacon after the deep sleep phase and shall not attempt any transmissions in this 
superframe. This is required in order to ensure that a device in deep power-save will 
first update its knowledge about existing reservations before making any own 
reservations. 
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Claims 

1. A method of decentralized medium access control in a communications network 
consisting of a plurality of stations, wherein devices include reservations for 
planned transmissions in their beacon frames. 

2. The method of claim 1, wherein a reservation is included in the beacons of the 
sending as well as receiving devices of the respective planned transmission. 

3. The method of claim 1, wherein the beacons of all terminals are grouped into a 
beacon phase. * 

4. The method of claim 1, wherein said sending device carries out a negotiation 
process with said receiving device prior to a new or a change of an existing 
reservation, characterized by 

• Said sending device sending a Reservation-Request to said receiving device, 
in which the starting time, duration, priority and if necessary also 
channel/hopping or code sequence is included. 

• Said receiving device answering said Reservation-Request with a Reservation- 
Response, m which the proposed reservation is either accepted or rejected. 

5. method of claim 4, wherein said receiving device proposes an alternative 
starting fame, duration or channel to the sending device in said Reservation- 
Kesponse. 

6. The method of claim 1, wherein the starting time of the reservation is given 
said beacon * Transmission Time of me dev >ee» which is sending 

7. Jhe method of claim 4, wherein the starting time of the reservation is given 
relative to the Target Beacon Transmission Time of the next following beacon of 
the device, which is sending the Reservation-Request, rsp. Reservation-Response. 

8. The method of claim 5, wherein a sleep-mode operation of devices characterized 

• a device entering sleep-mode, if it is not involved in any of the 
transmissions, that are announced in the beacon phase- 

" JhaS* 0 Wakl " S " P fr0m sleep - mode at me banning of each beacon 
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9. The method of claim 1, wherein devices maintain a table of all planned 
reservations that they have received or sent 

10. The method of claim 1, wherein a transmission consists of the following steps: 

• The receiver sending a poll packet to the sender 

• The sender sending the data packet to the receiver 

• The receiver acknowledging one or several data packets with an ACK 
packet. 



Deep Sleep mode etc.... 

11. A communications network consisting of a plurality of stations, including a 
plurahtyof stations, which include reservations for planned transmissions in their 
beacon names. 



